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This is the report of the productivity enhancement study 
of the FMSO software development effort. This study is an 
inrial effort to identify candidate projects for producrivi 



ty i mpro vemer.ts. 


We 


do not acre 


mpt a 


detailed analysis 


FM SO problems. I 


ns t e 


ad, we try 


to adopt an overview of 


organization a r I 


its 


problems as 


they 


appear tc outside 


It is the ccirion 


f 

~ 


the authors 


tha t 


FMSD is well man a 



and that employee morale is generally good, but that the or 
gar.i ration faces serious challenges in both the rear fern 
and the long term. Substantial changes will have to be ma 
in the way the organization does business to keep FSSO via- 
ble in the future. 

The major recommendations ir. this report are: 

1. FJ1SC should begin work on a Development Tools System 
that will support computer programming work, documen 
tatior. and software management. This should be a 
unified system (all parts of it can communicate with 
other parts) but net necessarily a single computer 
system. 

2. The physical facilities at F MS 0 are below the recog- 
nized standards for supporting a software developmen 
operation and should be upgraded. 
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3. Some ar^as cf software management need tc be im- 
proved. Notably/ a better project planning and 
tracking system needs to be put in place. Generally, 
FMSC's software management effort is well directed. 

The points covered in tills report are: 

1. An overall view of too r.-lSO systems effort. 

2. A discussion of the type of productivity enhancing 
effort that should be .made. 

3. A proposal for the installation of a Development 
Tools System at FhSC. 

4. An outline of the facilities improvements that should 
be made tc improve productivity and encourage contin- 
ued high employee morale. 

5. Project estimating techniques and their usefulness. 
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Chapter 1 
BACKGROUND 



1. 1 introduction to fmsg 

The Fleet Material Support Office is an unusual Mavv com- 
mand. It handles a variety of responsibilities tor the Sup- 
ply Corps, but most of its work is to function as a Central 
Design Activity for various supply and financial computer 
systems. In effect, FMSO is the information systems arm of 
NA VS UrSYSCCM. The major mission areas for FMSO are: 

1. Central Design Agency activities. 

2. Management of the Navy's Retail Stock Fund. 

3. Operations analysis activities. 

4. Supply operations support. 

5. International logistics. 



The 


CDA activ 


icy 


con sume 


3 90% of F 


[ISO 1 s 


r eeo arcs 


s , and 


it is 


th e 


area that 


we 


will 


be 


cone er n ed 


v it h 


in this 


report,. 


The 


major concern 


of 


this 


St 


udy is to 


i ecus 


on ways 


to incr 


ease 



the productivity of the CCA activity. 

The major functions supported by the CDA activity are: 
1. Uniform Automated Data Processing Systems (UDAPS) . 

a) Uniform ADP System for Inventory Control Points 
(UICF) . 

b) UADFS Stock Points (UADPS-SP). 
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c) Level II/III Stock Points. 

d) Disk Oriented Supply System (DOSS) . 

2. Headquarters Financial Systems. 

3. Management Information System for International Lo- 
gistics - MISIL. 

4. Special Data Processing Systems Projects. 

a) EtMMSE - Requisition Material Monitoring and Expe- 
diting . 

b) Trident logistics data. 

c) HALCCKIS. 

d) NATOS - Navy Automated Transportation Data System. 

e) NAVADS - Navy Automated Transportation Documenta- 
tion System . 

f) Resolicitation. 

g) SPAR. 

The list of responsibilities placed on EMSO is impressive. 

If it were a private organization, it would be a major soft- 
ware house or computer company. With approximately 1,360 
employees FMSO has a staff that is about 200 smaller than 
Apple Computer. The employees charged with the CD A activity 
have to maintain a library of computer systems consisting of 
approximately 10,000 - 1 2,000 programs totaling on the order 
of 20 million lines of code. In industrial terms, this sys- 
tem library is about what one would expect to find in a ma- 
jor high technology company that employed around 200,000 
people. This library has been in development for 10 to 20 
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years. Again, if industrial yardsticks apply, then it is to 
be expected that FMSO has spent between one and twc billion 
dollars in developing this code. 

1.2 GENERAL EBOBLEMS AT FMS O 

Seme of the problems that beset FMSO would occur in ar.y 
information systems group in any organization. Information 
systems activity is generally a service area. This means 
that others in the organization do not really appreciate the 
problems involved in developing software and have little 
idea about effective ways of doing it. They expect me ser- 
vice to be available when they want it and in the form that 
they want it. The result is that an information systems 
group can develop serious problems in its relations with its 
upper level management and its customers. The group has 



little control over 


planning or 


rasourc 2 allocation 


c ts 


area, but it tends 


tc get blamed 


for everything that 


gees 



wrong. In FflSO's case, this problem is iad-o worse by the 
fact that their superiors are in Washington, and their major 
customers are spread all ever the globe. The reputation of 
the organization suffers as a consequence even when its 
problems are net of i^s own making. 

Besides these general sorts of information systems group 
problems, there is another set of problems that arises for 
computing groups working for the government in general and 
for the Navy in particular. During the fifties and sixties. 
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computers were generally recognized as useful, but they were 
very expensive and difficult tc manage. As a result, a 
whole set of regulations grew up around the use and procure- 
ment of computers with the Brooks Bill being the item most 
often cited. The affect has been to require lengthy justi- 
fication for any computer procurement. 

The ironic thing is that computers have gotten much 
cheaper since these regulations were first put into effect. 
Computer power that would have required a mainframe twenty 
years ago can now be purchased at K -M art in the toy depart- 
ment. For. computer systems costing between 310,000 and 
31 00,000, the justification of the system is one of the most 
expensive accessories on the machine. There have been owo 
sia^ effects cf this. The first is to make managers reluc- 
tant to procure equipment even though it may be of consider- 
able benefit tc the organization. For the individual manag- 
er, a procurment effort means that his staff is occupied 
with the paperwork required to purchase a computer instead 
of being able to do their regular jobs. 

Another problem that affects FXSO is the Navy attitude 
toward shore facilities. There seems to be an unwritten 
policy in the Navy that the first priority should be given 
to the fleet while shore and support facilities are of sec- 
ondary importance. The socialization of Naval officers also 
leads them to accept shore facilities that are less than 
ideal. Shipboard life involves a lot of crowding and dis- 
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comfort. No matter hew bad a shore facility may be, it is 
likely to be mere comfortable and spacious than a shipboard 
facility. Unfortunately for FHSO, the standard of compari- 
son is not shipboard software development facilities (if 
there were such a thing) . It is the numerous software de- 
velopment facilities springing up all around the Harrisburg 
area. It will be irresistable for FMSO employees to compare 
their working conditions with those available at places like 
EDS and CACI. 

These comments apply to both the physical plant at FMSO 
and tc the computer systems upon which development is done. 
The computers for which F KSO dees development work must be 
among the oldest currently operating. This is a costly 
preposition from many points of view. For the individual 
programmer, it is costly because he falls behind techno- 
logically. Computer personnel are an unusual breed. Of all 
the professions, they hold professional development in high- 
est regard. This is natural considering that computer tech- 
nology changes rather quickly, and that any individual who 
falls behind is likely to find himself out of a job. FMSO 
has dene a good job in making professional development 
training available to its staff. This is probably a major 
reason for the remarkable loyalty to the organization we ob- 
served there. 

There are other problems in trying to deal with older 
technologies than just personnel considers tior.s . Both the 
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equipment and design philosophies for operaring systems have 
changed considerably since FMSO's equipment was insralled. 
Magnetic rape oriented systems for data processing are r.cw a 
thing of the pasr. Magnetic rape is cheaper than disk, bur 
its use requires a great deal of operator intervention. 

There are too many chances for error in the use of tape. In 
a disk oriented system, the process of calling files and 
setting up jobs is done automatically without human inter- 
vention. The disk system may be more costly to install, but 
the elimination of tape handling errors makes it a good deal 
cheaper in the long run. 

The same is true of older operating systems. Such sys- 
tems generally called for more operator intervention. This 
opened up more chance of error. The newer philosophies in 
operating systems call for "programming the idiot out of the 
loop" - that is, designing the system so that it rarely 
calls on humans for decisions. A final point in the opera- 
tion of older systems is the maintenance problem. As a sys- 
tem ages, the manufacturer of the system becomes less inter- 
ested in performing software enhancements and updates. He 
naturally wants to concentrate on newer products, and even- 
tually the software on the older system becomes obsolete. 

If the customer does not upgrade his hardware, he gets left 
behind in the evolutionary process of system development. 
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1.3 



PS0BL2MS IN REACHING A SOLUTION 

The problems mentioned above combine to n'ake long tern 
solutions very difficult in this environment. Acquisition 
of new computer systems or the institution of long range 
changes can take years in the Navy environment. An example 
of this is the IC? Resoli cita tio n project. This nas been 
underway for about eight years now, and the first machine 
should come on line in 19 84 (if all goes well). This is an 
un conscicr.ably long time for a systems change. In an indus- 
trial environent, this should take no more than a year with 
only a few months spent on the study portion. 

A critic of FM 33 might argue that this only proves that 
the machines were unecessary in the first place and that the 
government has saved itself eight years of computer expense 
by staying with the old equipment. This is all quite true. 
The machines are "unnecessary" in the sense that there is 
always another way to do a computer job. In this case, the 
computer savings were generated at the expense of personnel 
costs, project delays and degraded service for the naval 
supply system. 

Unfortunately, the personnel costs do not get charged off 
to specific information processing systems in quite the same 
way as a computer. If they don't appear on anybody's bottom 
line, then there is a tendency to regard these costs as not 
being real. 
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The Univac 495's that NA’/SUP uses to manage the ICP's 
were obsolescent whan the system was installed in 1955. By 
now, they are hopelessly out of date. what this means is 
that because of the Navy's "can do" attitude, these machines 
have been kept going long past their useful life. The price 
for this is mere operations personnel, time spent on systems 
development and changes to the operating system, and time 
spent fine tuning FhSO's applications to get the most possi- 
ble "bang per buck" out of a Univac 494. There is little 
doubt that TCP's Univac 4 94’s have been tuned so that they 
are operating more efficiently (where efficiency is measured 
in computer time only) than any Univac 494 's in history. 

Why anyone would want to do such a thing is another ques- 
tion. 

1 . 4 CONCLUSIONS 

The Commanding Officer cf FM30 faces several significant 
challenges. The organization has some real long range prob- 
lems. These include systems upgrades, improvements that 
need to be made to take advantages of new technologies and 
improvement of the physical environment. The steps we re- 
commend to solve some of these problems are going to gener- 
ate short range chaos. A CO's tour of duty is only two 
years. If a new CO came in and accepted ail of our recom- 
mendations on the first day of his tour, then by the end of 
his tour FMSO would be in a much more disrupted state than 
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when he took ever. In fact, the same would probably be true 
cf his successor, and it would net be until the third CO in 
the sequence that we would begin to see payoffs iron some cf 
the productivity measures we will recommend (about five 
years out) . FMSO is already engaged in a number of steps to 
solve the problem areas we observed. Things seemed to be 
moving in positive directions and the management was well 
aware of the challenges facing before this report was writ- 
ten. 
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Chapter 2 

APPROACHES IN IMPROVING PRODUCTIVITY 



2. 1 INTRODUCTION 

There are isny possible approachs to improving prcductiv 
it y in software development. There is no one magic techni- 
que that will guarantee results under ail conditions. The 
most effective techniques to apply in improving productivit 
will depend on the current status of the organization, its 
level of expertise, and the type of systems and management 
environment ir. which it operates. In addition, the ap- 
proaches to productivity improvement given in the literatur 
tend to be interdependent. They cannot be applied separate 
iy or piecemeal and have any chance of achieving success. 
For example, modern software management techniques cannot b 
used effectively in an antique computing enviroment. Most 
of the productivity improvement techniques are highly depen 
dent upon interactive computing environments, sophisticated 
development tools and the ability to transfer both develop- 
ment code and administrative data quickly among the individ 
uals involved in a project. On the other hand, high tech- 
nology by itself is no guarantee of a productive 
environment. A productivity improvement program needs a 
well thought cut managment plan combined with the latest 
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technology. In this document, we will try to lay cut the 
aspects of a productivity enhancement program for FMSO. 

2. 2 PROBLEMS IN DEFINING PRODUCTIVITY 

The first problem with productivity in a software envi- 
ronment is deciding what it is. This may sound odd at first 
because everyone thinks that they knew what productivity is. 
In a manufacturing environment such as the automobile indus- 
try, it is not toe hard to come up with definitions for pro- 
ductivity. An automobile is a tangible item. It either 
works, .or it dees not. It is built from components that are 
easy to cost cut and a cost for its production can be com- 
puted fairly readily. 

In software development, this is not the case. It is 
hard to come to some sort of solid analysis as to just what 
is being produced by programmers. In cne sense, it is not 
too different from the case of an automobile. Programmers 
produce programs, and these programs either work, or they do 
not. But each programmer working on a system produces only 
a piece of it, and there is no set standard for measuring 
what these pieces are. The measure most commonly used in 
industry is lines of code. All we have to do is count the 
lines of code produced by a programmer, and divide that into 
the cost cf supporting the programmer, and we have a produc- 
tivity figure that we can use. 
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But when one begins to examine both the published litera- 
ture ana the possibilities available in the definition of 
lines of code, one's confidence in this measure begins to 
slip away. For instance, what do you count? Is every com- 
ment line in a program counted, or do we only count executa- 
ble code? Do we count the lines in a program that contain 
commands to the operating system, or do we only worry about 
the source language code? What do we do about code that has 
been produced for another system and has been re-used for 
the system that we are trying to analyze? Can we count code 
that has been produced by a program generator? The list of 
possible questions is almost endless. 

One reply tc this is that it does net really make too 
much difference. All we have to do is cnocse some reason- 
able measure and stick with it. Indeed, this is what most 
organizations do. But, this does make it hard to compare 
productivity across organizations. It is not uncommon to 
find "productivity" differences that are almost an order of 
magnitude apart in comparing two different software organi- 
zations 1 . In many cases, much of this difference in produc- 
tivity comes from differences in the counting conventions 
that are applied to computer code. It would be a mistake to 
accept these differences at face value as true differences 
in productivity. 



1 See Barry Bcehm, Software Engi neeri ng Ec on o mic s, p. 86 for 
a table listing the different effort models and a brief 
comparison cf the number of man-months predicted by each 
for a software development project. 



12 



X her* are ether possibilities fer measuring the output o 
a software effort. It is possible to define the basic func 
tiers performed in a program, and then count productivity a 
number of functions implemented 2 . Another possibility woul 
be to count number of programs released. Both of these are 
somewhat grosser measures than lines of code, ar.d in their 
own way, they can be as hard to implement. No matter what 
measure is chosen for productivity in an organization, cars 
should be taken in its application. One does not want to 
come up with a measure that encourages behavior that is 
counterproductive. For example, if one chooses lines of 
code as a measure then checks should be made from time to 
time to make sure that this is not encouraging programmers 
to use ceding techniques that maximize lines of code. Simi 
larly, if one choose programs released as a measure, than i 
would be to a programming team's advantage to only try to 
work on short, simple systems. This would boost their "pro 
ductivity" measure as defined by the organization. Whateve 
measure is chosen, it should be applied with common sense, 
examined frequently and compared with other measures of pro 
ductivity. Slavish adherence to an inappropriate productiv 
ity measure could do more damage to real productivity than 
not paying any attention to productivity at all. 



2 For an example of this approach, see the article by A. J. 
Albrecht, "Measuring Application Development Productivi- 
ty". 
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2.3 PRIORITIES IN IMPROVING PR ODU CTIVITY 

In improving programmer productivity at FMSO, we have a 
few problems because there is no currently accepted defini- 
tion of product! vity in place at FMSO. This means that we 
could institute programs for productivity improvement, but 
we have no way cf measuring hew well these programs perform 
One approach to this problem would be to set up some proauc 
tivity measures, gather data and use this data as a bench- 
mark for future productivity enhancement measures. We feel 
that this would be- a bad approach. The problems that FMSO 
has are serious enough, and the organization is enough be- 
hind the current state of the art in information systems 
technology that we feel that certain measures must be taken 
without delay. In setting up a productivity improvement 
program at FMSC, we feel that the following areas should be 
considered (in order cf priority) : 

1. Automation of the systems development process. 

2. Improvement of the physical environment at FMSO. 

3. Development of a system of productivity measurement 
and data gathering to support this system. 

4. Development of a system for project planning and 
tracking based on the productivity measures devel- 
oped. 

5. Continue the work on a set of automated development 
tools in support of the systems development effort. 
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All of these problems are serious, and to a certain ex- 
tent, they must all be attacked simultaneously. We feel, 
however, that the automation of the software development 
process is the most important issue to be solved in the near 
term. The highest priority should be given to the acquisi- 
tion of a development tools system to aid in both software 
development and project management. A major problem at FMSO 
is that development takes place on "test bed" machines. 

Such machines are set up tc meet the needs of the organiza- 
tion for which the software is being developed. They do not 
have the full set of software aids that one would expect c.n 
a modern software development facility (sophisticated text 
editors, interactive compilers, file transfer protocols, 
message handling facilities, and word processing text for- 
matters) . These tools are- not necessary for the ultimate 
missions of these test bed machines. However, these auto- 
mated tools are very effective f cr software development and 
project management. Further, because the development ma- 
chines are identical to the actual production machines, the 
temptation to pre-empt development activity if one of the 
production machines is down is very strong. The immediate 
needs of users naturally have a higher priority than long 
term development projects, and this can result in slowdowns 
in development. The "test-bed" machines are actually the 
production machines of the development groups, but users 
tend to overlook this. It must be recognized that software 
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development is a highly specialised activity, and chan it 
needs its own production facility. There is no reason why 
the development system has to be the same machine as the one 
for which the software is being developed. In fact, devel- 
oping the software on a different machine could actually 
serve to make the code more readily pcrtaole. 

2.4 THE CASE FOR A DEVELOPMENT TOOLS SYSTEM 

The development tools system should serve both management 
and programmers. It is hard to separate the needs of the 
programmers and the project managers in a large software ef- 
fort. If anything, the larger the software effort, the mere 
time and effort will be spent in management ana documenta- 
tion issues. For a large system, actual coding is likely to 
consume about 30% of the effort. The remaining effort is 
spent in documentation, management and coordination of the 
diverse elements making up the system. Any development 
tools system iaplemented should be able to support these 
needs. A unified development tools system should be able to 
support these functional areas: 

1. Development documentation. 

2. Project management and tracking. 

3. Budgeting. 

4. Program coding. 

5. Program testing. 

6. Database development and program test data. 
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7. Quality assurance. 

To those used to cider generations of equipment, this may 
sound like an impossible list of tasks for a srngle comput- 
er. In fact, this list is the rule rather than the excep- 
tion on modern large scale computers. Most mainframes offer 
a wide variety of tools that will support this type of envi- 
ronment . 

The processors needed to support systems development in- 
clude: 

1. Interactive compilers. 

2. Languages with string processing capabilities. 

3. Text processing packages for formatting documenta- 
tion. 

h. Sophisticated file handling capabilities. 

5. Screen crrented text editors for manipulating both 
code and text. 

6. The ability to transfer data from one user to another 
quickly and conveniently. This would be used for 
both automated office type applications and program- 
mer’s wcr k b en ch . 

7. Packages for doing statistical analysis. 

8. A graphics system fcr producing documentation and 
management reports. 

9. Automatic typeset facilities for producing "clean" 
documentation and reducing printing costs. 
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The idea is that a development system should support a wide 
variety of both computer related and management related ac- 
tivities. Some may object to the proposal that text pro- 
cessing abilities should be included on the development sys- 
tem. The counter argument would run - "We already have word 
processing facilities. Why buy more?". What we are propos- 
ing here is somewhat different from the normal word process- 
ing systems. The development system would be used to tie 
together a number of different applications, and word pro- 
cessing would be one of them. It is very convenient and 
cost effective to be able to do both programming and word 
processing on the same machine. For one thing, it allows 
you to take the output of a program, reformat it and use it 
as part of the text in a manual. This is difficult to do on 
an ordinary wcrd processing system because it involves re- 
entry of data that was already generated by the computer 
anyway. The strategies for building a development system 
are discussed in Chapter 3. 

2.5 IMPROVING THE PHYSICAL PLANT 

Almost as important as the acquisition of a development 
tools system is improvement of the programming environment 
at FMSO. The present facilities are inadguate for any type 
of clerical work, particularly computer programming. FMSO 
is housed in an old warehouse building. The space inside 
the building is broken up using shoulder height partitions. 
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These partitions are of the old-fashioned sort that do net 
provide much sound insulation. The building itself is noisy 
and poorly air conditioned. This is the worst environment 
for software production that we have ever seen. 

The present facilities provide about 50 square feet of 
floor space for each employee. In the computer industry, 

100 square feet is considered normal 3 . Programming is ar. 
activity that requires somewhat different types of office 
spaces than a other clerical jobs. The by-products of com- 
puter programming {listings, sheets cf graphics output, man- 
ual libraries) take up a great deal of work space and stor- 
age space. To use them effectively requires specially 
designed work areas ar.d storage areas. A programmer needs a 
desk* for normal work, a work table where he can spread out 
listings or notes for work (even with a more modern system 
that de-e mphasizes hardcopy, it will be a while before all 
programmers accustom themselves to this) , a terminal for in- 
teraction with the computer and storage areas for listings 
and manuals. It goes without saying that this all should be 
in the context of a physically comfortable environment. The 
air conditioning should be adequate to the climate, and the 
sound insulation should be coed. In addition, there have to 
be conference facilities readily available for meetings cf 



3 See the description of the IBM Santa Teresa labs which 
were specifically designed to support software develop- 
ment. The reference is G. M. McCue, "IBM’s Santa Teresa 
Laboratory - Architectural Design for Software Develop- 
ment". 
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project teams. Program development for a large system is a 
relatively social activity, and this meeting space is needed 
for the jot as well. The command seems to be well aware of 
the space problems and is taking steps to remedy them. Seme 
of the problems will be alleviated in the future as systems 
work moves away from cards and the floor space taken by card 
files can be reclaimed. 

The issue of programming environment is an important one 
and is addressed in Chapter 4. There are no specific stud- 
ies relating programming environments to productivity. As 
we discussed earlier, productivity measures are rather rub- 
bery, and it wculd be statistically difficult to relate spe- 
cific productivity measures to all cf the possible variables 
in environmental design. Still, if your building layout is 
substantially at variance with what is considered normal in 
the the industry, then your programmers are likely to no- 
tice. FMSO is ringed by software houses (2DS, CACI and oth- 
ers) , and the program development environments there are 
likely to come a lot closer to industry norms than they do 
at FMSO. Eventually FMSO is going to lose many of its best 
employees to these organizations because they perceive a 
better environment there. It is a tribute to the management 
practices in place at FMSO that the employee morale is as 
good as it is. 
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2.6 CONCLUSIONS 



The observations we have made ir. this chapter should come 
as no surprise. From our conversations with ?:•! SO staff, 
these are well known problems. They do not seen to be wide- 
ly known outside the organization, however. We feel that 
FM SO is at a crucial point in its existence. It has to ei- 
ther improve its technical and physical facilities, or it 
will cease being a viable software development organization. 
The options are either to improve the facility or to abandon 

r i. 

The process of productivity improvement must be attacked 
on several fronts. The most important is the improvement of 
the technical and physcial environment. It does not make 
sense to try to implement modern software management techni- 
ques in a horse and buggy technical environment. The im- 
proved software management techniques will be helpful in any 
environment, but they will not be as effective on a non- in- 
teractive, antique computer system. Along with the improve- 
ment of the system, an acceptable measure of productivity 
must be developed and installed. All of these changes are 
evolutionary, and will take a good deal of time. There are 
no generally accepted productivity measurement techniques in 
industry. The models used tend to be tailor made for each 
organization, and the same will be true for FHSO. 
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Chapter 3 

REQUIREMENTS FOR A DEVELOPMENT TOOLS SYSTEM 
3. 1 INTRODUCTION 

Since the Development Tools System is to be installed in 
a Navy environment, the first thing to consider is the pro- 
curement cf this type of equipment. To somebody accustomed 
to industry standards for software, the lead times for gov- 
ernment software procurements seem excruciatingly long. The 
ICP Resolicitation effort at FMSO has been going on for 
eight years new, and the first machine has yet to arrive. 

In industry, eight years would be the complete life cycle 
for the system from the first feasibility study to the final 
departure cf the system at the end of its life. In the 
past, such long life cycles have guaranteed that the equip- 
ment will be obsolete when installed. 

Part of the problem is that a great deal of economic jus- 
tification is required for a government procurement. There 
is nothing wrong with this per se, but this economic justi- 
ficataticr. is always tied to a specific shopping list of 
hardware, and the whole thing has to go through many levels 
of approval. Meanwhile, the computer industry changes at a 
rapid pace, and the list of hardware quickly becomes obosc- 
lete. It would be worthwhile to consider the approach taken 
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by the SPLICE project in acquiring a system. The focus 
should be cn the functions that they system is to serve ar.d 
not or. the specific list cf hardware to accompiisn those 
functions. The system itself should be modular and expands 
ble. Once a procurement authorization is in place, it can 
be used as a vehicle for future upgrades to the system. 

This is being done in current Navy procurement (including 
the ICP Resolicitation) , and it may help to relieve seme cf 
the past problems. The procurement document is regarded as 
a vehicle for future upgrades and the need for re-justifica 
ticn of upgrades should be avoided. The same sort cf focus 
should be used in the acquisition of a Development Tools 
System. 

3. 2 FUNCTIONAL CAPABILITIES REQOIRZD 

The functional capabilities in the Development Tools Sys 
tern should include: 

1. Interactive compilers and debugging tools for system 
development in the major languages used at FMSO. 

This would be COBOL and perhaps FORTRAN. 

2. Interactive languages with good string processing ca 
pabilities for use as tool generating languages. 
These would be used to generate data bases, and de- 
velop automated tools for analyzing computer code 
(structure and standards checkers would be two exam- 
ples) . Good candidate languages would be PL/I or 
Pascal. 
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3 . 



High speed terminals with full screen editing capa- 
bility. Ideally, there should be a terminal for each 
programmer. 

а. An electronic mail system so that programs, documen- 
tation and data could be routed readily among the 
members of the development team. Such a system could 
serve as the foundation of the development and man- 
agement work on FM SC systems. 

5. A variety of management tocl aids such as statistical 
packages (SPSS, Minitab), management packages (PERT) 
and report generating packages (RAMIS II or FOCUS) to 
aid in controlling the development of FMSO projects. 

б. A sophisticated word processing capability that would 
include the ability to format large documents (the 
requirements tend to be different than for small word 
processing systems). Examples of systems of this 
type would be Script or ATMS. 

7. A sophisticate d graphics capability for producing 
both documentation and management reports. 

8. An automatic typesetting system tied in with a high 
speed laser printer. 

This is a formidable set of requirements for a single ma- 
chine. A number cf manufacturers supply equipment that 
could handle these requirements, but it would probably be 
more economic to consider a Local Area Network (LAN) rather 
than to try to satisfy all of this on a single machine. The 
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networking system chosen would be the vehicle for future 
system growth. Increments to this computer power could be 
addsc as needed. 

at the base of this network, there would have to be one 
or mere reasonably powerful mainframe systems. These would 
be required for implementing programming tools and for doin 
interactive testing of code. Individual editing and word 
processing functions could probably be handled on smaller 
"smart" terminals. It makes more sense to download process 
ing onto cheaper micros and minis rather than trying to fir. 
a large CPU to handle everything. 

3.3 COST JUSTIFICATION FOR THE DEVELOPMENT TOOLS SYSTEM 

It will be difficult to do traditional economic analysis 



on such a system 


for cost 


jus tif ica tior. The 


normal govern 


ment approach to 


scon cmic 


analysis on systems 


is to aster- 



mine requirements, cost out a set of alternatives for meet- 
ing these requirements and then choose the most cost 
effective alternative for the system. There is nothing 
wrong with this, but it does make one rather large assump- 
tion at the start - namely that you can determine your "re- 
quirements". In FMSO's case, this will simply not be true. 
The software development environment there is so far behind 
current technology that the programmers could not even stat 
exactly how they will use the new system. Our experience a 
NPS is probably instructive. 3e£ore we acquired cur IBM 
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3033AP system, we went through the standard justification 
and benchmarking based on the best guesses we could come up 
with on how users would use the new machine. These guesses 
proved to be totally inadequate because our users were very 
quick to come up with unanticipated uses of the machine. 

This is the problem of trying to assess "unmet demand" in 
advance. In FMSO's case, the problem is likely to be an or- 
der of magnitude worse because the systems in place there 
are sc old. It will take the programmers at least a year 
before they begin to feel comfortable with the machine. 

Once they do feel comfortable with it, they will begin to 
use it in ways that are hard to anticipate. A LAN type 
technology will at least allow you to expand your resources 
in a modular fashion. 

3.4 CONCLU SION S 

FMSO should try to remain as flexible as possible in its 
acquisition of a Development Tools System. Fortunately, 
this is relatively easy to do with newer computer systems. 

It is possible to buy a system as a set of building blocks 
and integrate and expand the system over time by adding new 
pieces. FMSO and the Navy generally need to change the way 
they think about computer systems. A computer system is not 
a solution to a problem. This type of thinking leads plan- 
ners to believe that a particular system is good now and 
forever. A computer system is a part of a problem solving 
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is probably a good idea 



process. As the process changes, it 
to consider changing the system as well. NA VSUPSYSCOd has 
failed to do this with its com pa ter systems, and it will be 
a difficult, expensive process to upgrade. 

Newer trends in Navy procurement make it easier to ac- 
quire useful computer systems by focusing on the functions 
provided by the system rather than on a shopping list of 
computer hardware. FMSO needs to look at developing an in- 
tegrated system that will support program development, docu- 
mentation, tools development and management. The system de- 
veloped should be expandable so that the system can grew as 
FMSO's needs grow. The most promising candidate for this 
type cf system is the local area network approach. The LAN 
technology is still fairly new, and it a>ay be a few yaars 
before there are any clear leaders in this field. In the 
meantime, Fh SO should begin working cn an overall develop- 
ment plan and begin acquiring equipment that could provide 
short term aid and also be rationally fitted into a LAN de- 
velopment in the future. 
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Chapter 4 

PROGRAM MING ENVIRONMENTS AND PRODUCTIVITY 
4. 1 INTRODUCTION 

The concept of programming environments is one that is 
just beginning to get attention from researchers in produc- 
tivity. The development of computer software is still in a 
cottage industry phase. It is not unusual for a programmer 
to have tc write the code, keypunch it (or do the data entry 
on a terminal), document it, keep track of modules, inte- 
grate modules, test the modules, assemble the release pack- 
age and a number of other chores associated with the pro- 
ject. This would be similar to having an automotive worker 
be the designer cf a car, write the owner’s manual, assemble 
the car and be responsible for doing maintenance work on it. 
This would require personnel who were much mors skilled than 
current automotive service personnel, and cars would be a 
great deal more expensive as a consequence. 

This problem that programming work has is just an example 
of general problems in the clerical area. Capital expendi- 
ture par worker is lower for white collar workers than for 
any ether type. The average per capita capital expenditure 
for white collar workers in our economy is $3,000. The cor- 
responding figure for blue collar workers is $25,000 and for 
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farm workers is 335,000. Productivity is harder to measure 
in clerical areas. Parhaps part of the problem is that man 
agers feel that office workers are not really producing any 
thing anyway, so why spend any money on them. This atritud 
is crumbling in the face of office automation, but it will 
be a while before it disappears. 



4.2 ELEMENTS OF A P50G3AMMING ENVIRONMENT 

When we talk about a programming environment, we are 
talking about a whole complex of support facilities for a 
programmer. Specifically, the points covered in the idea 
in cl ude : 

1. Tools support - access to convenient, up to date 

technologies . 

a) Interactive systems. 

b) Flexible data editing facilities. 

c) Text formatting and document preparation. 

d) Electronic mail. 

e) Interactive compilers. 

f) Flexible interactive terminal systems. 

2. Architectural environment. 

a) Comfortable workspaces. 

b) Adequate storage for documentation and listings. 

c) Library facilities. 

d) Conference and meeting facilities. 

3. Team support. 
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a) Cara entry personnel. 

b) Program and data libararians. 

c) Technical writers. 

d) Management aides. 

a) Adequate secretarial support. 

4. Social support. 

a) Professional development seminars. 

b) Training opportunities. 

c) Access to technology. 

The requirements of a programmer in a systems development 
environment are basically threefold. They are: 

1. Privacy for program writing activities. 

2. Meeting areas for social interaction on project work. 

3. System access for program testing. 

Anything that undermines these requirements will undermine 
the programming environment generally. 

4. 3 IMPROV EME NTS IN PRO D0CTI7I TY DOE TO IMPROVED 
ENVIRONMENT 

Prom F M SO 's point of view, the most interesting question 
is how much productivity will be improved by improving the 
development environment. This will be necessary for any 
cost justification of improvement. It turns out that this 
will not be an easy question to answer for a variety of rea- 
sons. First of all, there is no real system of productivity 
measurement in place at FMSO, so we have no way to measure 
productivity. Secondly, FMSO is a unique environment. In 
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most ways, it is fat behind current computer technology. It 
is doing development in a computer environment that most or- 
ganizations scrapped ten years ago. Its management climate 
is mere up to data. The improved programming technologies 
are given in the development handbooks, the staff as aware 
of them and seems dedicated to implementing those that can 
be adapted to FMSO' s situation. 

It is this combination of factors that makes comparison 
with industrial experience difficult. Most of the research 
on productivity improvement deals with the improved program- 
ming technologies. There is little worx done on a compari- 
son between interactive vs. catch modes of program develop- 
ment. The reason for this is simple. Everybody considers 
interactive ceding to be such an improvement that nobody has 
bothered tc research the question lately. There were a few 
tentative papers cn the subject in the late 19b0's, but 
there has been little recently 4 . 

The programming styles cf the workers will be different 
in interactive environments than they will in a batch envi- 
ronment. When a programmer does development work in a batch 
mode, he has tc keep several projects going concurrently. 



4 See Harold Sackman's article, "Exploratory Experimental 
Studies Comparing Online and Offline Programming Perform- 
ance" published in the Communications of the Association 
fo r Co mput in g Mac h i ns r v in January 1963. Sackman's arti- 
cle concluded that there was about a 20% improvement in 
programmer time using an interactive system. It should be 
noted that study used the relatively crude interactive 
systems cf the late 1960's. Today's screen oriented sys- 
tems are orders of magnitude better than the early inter- 
active systems. 
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This way, he has something to do while waiting for the out- 
put of his last computer run. This also means that there is 
a setup cost each time he shifts gears from one project tc 
another. In an interactive environment, a programmer is 
able to concentrate on a single project until it is complet- 
ed. He does not have to clan his work around the difficul- 
ties of computer access. This would suggest that interac- 
tive systems development should have high payoff in a 
maintenance oriented environment like FMSO's. For most 
main tenan ce work, the c ha nges to a program tend to be small 
and could he completed quickly. An interactive system could 
also be useful in controlling the forms and documentation 
associated with program development. 

4.4 CONCXOSICMS 

Mere attention needs tc be given to the issue of program- 
ming environment at FMSO. The major points that need im- 
provement are the physical and technical environment. These 
have been amply covered elsewhere. But simply improving 
these aspects of the environment is not enough. When the 
new system is installed, work should also begin on providing 
support tc developers in the form of improved tools, secre- 
tarial assistance and general programming team support. 

This will allow FMSO to reap full benefit from the new tech- 
nologies. 
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Chapter 5 

A PRODUCTIVITY MEASUREMENT SYSTEM 
5. 1 INTRODUCTION 

This chapter will discuss the measurement of prcductivi 
within the software development and maintenance process. 
Productivity measures, when defined as a measure of output 
divided by a treasure of input, are used for measuring the 
efficiency of any production process. Productivity measur 
can provide information on efficiency at all levels of an 
organization. These levels include various projects and d 
partmer.ts, as well as the entire organization. This chart 
will examine the purposes cf productivity measurement, the 
productivity measurement problem in general, various meas- 
ures cf programming productivity and a brief discussion cf 
the implementation of a productivity measurement system. 

5.2 PUR POSES CF PRODUCT IVIT Y MEASUREMENT 

The primary purpose for measuring productivity in the 
software development and maintenance process is to provide 
information for use in the three major phases of software 
management. These phases are the planning, control and 
evaluation of the entire software process as well as indi- 
vidual projects within the process. 
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5. 2. 1 Planning 



The primary function of the planning phase of software 
management is to provide a prior estimate of resources re- 
quired for supporting the software development and mainte- 
nance process, either on a project basis or on a recurring 
basis for the entire software department. The planning 
phase allows for the establishment of budgets for J -he de- 
partment and projects as well as subbudgets for each of the 
input factors, especially labor, which are required in the 
software process. The productivity measure is used, along 
with an estimate of the amount of output required for the 
project cr department, to generate an estimate of the amcun 
of input (s) required for a given time period. It should be 
noted that there exists a direct link during this phase be- 
tween the productivity measure and project cost estimating 
methods. Cn a project basis, the productivity measurement 
problem is equivalent to the project ccst estimation prob- 
lem. 



5.2.2 Control 

The control phase of software management entails the de- 
termination of the extent cf progress of the software pro- 
cess and may be applied at both the department and project 
level. Progress nay be measured on two dimensions, budget 
ar.d schedule. On the budget dimension, actual expenditures 
are compared with planned expenditures and variances are ex 
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amir.ed. Adequacy of progress is measured by These varianc- 
es. The planned expenditures, which were generated during 
the planning phase, usually serve as the standards for meas- 
uring progress. However, the plans are subject tc modifica- 
tion duo to unforeseen contingencies. 

On the schedule dimension, actual elapsed times are com- 
pared with planned elapsed times and, again, variances are 
examined. As in the case of budgets, planned schedules 
serve as standards except when modified by unexpected 
events. Productivity measures are used in this phase to as- 
sist in the determir.a~.ion of actual budgets and schedules, 
as well as tc assist in the modification of plans when con- 
tingencies cccur. 

5.2.3 Evaluation 

The evaluation phase of software management concerns it- 
self with the determination of how well the software process 
is meeting the goals cf the organization. This determina- 
tion may be made at the department level, the project level 
or any intermediate level. An integral part of this deter- 
mination of the adequacy of the entire process is an evalua- 
tion of the efficiency of the process. Productivity meas- 
ures, functioning as pure efficiency measures, are useful 
during the evaluation phase. 
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5.3 PBODOCTIVITI M EASUR 3ME NT IN GENERAL 



Productivity is defined as the relationship between the 
output of goods and services and the inputs used to produce 
those outputs. Two general types of productivity ratios ar 
generally used: total factor productivity and partial fac- 

tor productivity ratios. Total factor ratios include all o 
the inputs in the production process, wnile partial factor 
ratios do not. The inputs or factors of production are gen 
erally classified into three major categories: labor, capi- 
tal and materials. A total factor ratio may be able to dis 
tinguish subclasses within each of these major categories. 
For example, labor is not homogeneous and different types o 
labor, such as skill levels, may be appropriate. Any facto 
may be used but labor is in common usage as a partial meas- 
ure with the input measure generally being man-hours or 
man-years. Nets that the use of partial measures may be 
misleading since changes in one input have effects upon all 
other inputs as well as output. Consequently, an increase 
in output per man-year indicated by a partial ratio should 
not be interpreted to mean that the increase is due solely 
to the increased efficiency of labor. This is because the 
increase in output is a result of all of the factors of pro 
ducticn working together. 

Productivity ratios are affected by both short and long- 
run elements. Probably the most important of the short-run 
elements is the change in utilization of productive capaci- 
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ty. Productivity ratios generally vary inversely with 
changes in the degree of capacity utilization since the fix- 
ed inputs cannct be varied with changes in output. Other 
elements causing short-run changes in productivity are both 
the level of effort and the learning process which occur as 
individuals adapt to new methods and equipment. Among these 
elements causing long-run changes in productivity are chang- 
es in the quality of inputs. Such changes are referred to 
as input-augmenting technological change. Perhaps most im- 
portant of the long-run elements are changes in the methods 
of organizing production. These changes in the underlying 
production function a re a result of such items as changes in 
the organizational structure or changes in managerial abili- 
ty. 

There are several problems involved in the use of produc- 
tivity measures. These center around ths measurement of in- 
puts and outputs and their abilities to measure efficiency. 
When measuring inputs for use in a productivity measure, it 
is desirable tc ensure that only the inputs that are actual- 
ly utilized in the production process are used in the meas- 
ure. This is especially important for the labor input ar.d 
implies, for example, that only time worked should be uti- 
lized in the measure instead of time paid. Although time 
paid may be of interest since it corresponds to the total 
cost incurred, it is important that such items as adminis- 
trative time, etc. be separated out. This will enable man- 
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agers to fccus mors carefully upon the ssoarate activities 
of productive work and other work. Also, it is imperative 
that only inputs which are homogeneous be aggregated. Using 
labor as an example again, different skill levels, such as a 
keypunch operator versus a systems programmer, perform en- 
tirely different tasks and should be aggregated only when 
they are occur within a particular department. It is also 
preferable to measure inputs in terms of physical units. 
Value units may also be utilized but physical units should 
be used if availacle. 

A primary problem with the measurement of outputs is that 
convenient measures are sometimes not available either ir. 
physical unpts or value units. This output measurement 
problem occurs principally within public sector organiza- 
tions. In this case, there is usually no accepted opera- 
tional definition of what the outputs really are (national 
defense, welfare, etc.), and the outputs are not traded in 
any markets so that value measures are unavailable, also. 
Consequently, most of the cutout measures in use are actual- 
ly intermediate outputs or, simply, inputs to further pro- 
cesses. Sucn measures are weak, at best. 

In the cases where inputs and outputs may not be precise- 
ly measured, the productivity measure becomes susceptible to 
perverse incentives and gaming. This implies that the con- 
trol and evaluation phases of management may focus upon 
faulty indicators. For example, if the output measure is 
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not truly output, there is some danger that generation of 
input may be encouraged rather than output. This increase 
in inputs does not necessarily imply increased our out. 

Also, use of such measures may provoke rhe generation of 
useless output. In one instance in the public sector, rhe 
measure was square feet of buildings cleaned. This resulred 
in many areas being cleaned rwice daily and some areas not 
at all. 

Ancrher major problem with producriviry measures is hew 
to deal with the quality of curput. Ostensibly, rhe qualify 
of output should be held ccnsrant in product. iviry measures 
but changes in qualiry may be difficulr to measure. Quality 
changes can cause difficulties in both directions; qualiry 
deterioration may'cause the measure to increase, while qual- 
iry improvement may cause the measure to decrease. 

A final problem is that changes in one partial producriv- 
iry measure can be misleading concerning its effects upon 
the entire production process. There are numerous ways ro 
obtain a given output with several inputs. Technical effi- 
ciency exists when, at a constant output level, reduction, of 
one input necessitates an increase in another input. How- 
ever, economic efficiency exists when the relative marginal 
costs of utilizing ail inputs in production of the output 
are the same. Technical efficiency is required for economic 
efficiency but not vice versa. Note that neither of these 
two concepts of efficiency are captured oy partial prcduc- 
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tivity measures. 0 verdependence upon partial measures for 
control and evaluation can result in underutilization of 
particular inputs which leads to less rather than mors effi- 
cient use of resources. 

5.4 MEASURING PROGRAMMING PRQD UCTI7ITY 
5.4.1 Introduction 

Keeping in mind the above discussion of productivity 
measures in general, we can now begin to discuss the soft- 
ware programming productivity problem. Programming is one 
of the major inputs into the software development and main- 
tenance process. Note, however, that programming is an in- 
put to this process; it is not the output. The output of 
the software process is usable software. Other definitions 
and measures of this output abound but all are simply fur- 
ther derivations on this one concept. Most output measures 
which are currently being used in programming productivity 
suffer from being either pure or intermediate inputs. Phys- 
ical measures, such as programs, do not address the problem 
that users of software are not interested in programs but 
are interested only in the output from the programs. Value 
measures, such as revenues and sales, are available for pri- 
vate sector entities but are not availaDle for public sector 
organizations, such as FMSO. Because the definition of the 
output from the software process is so equivocal, several 
alternative measures are being utilized currently. These 
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generally cluster around lines of code produced in the pro- 
gramming process, functions which the program performs and 
functions which the user performs when utilizing the pro- 
gram. Additionally, most variations on these measures use 
some measure of labor to generate a (partial) productivity 
measure. Productivity measures using these three major 
types of output measures as well as an additional one, com- 
pleted projects, are evaluated below. 

5.4.2 Lines cf Code 

The productivity measure using lines of cede is usually 
lines of code per labor unit, where the labor unit may be 
man-days, man-weeks, man-months, etc. Lines of code is a 
physical measure; however, it measures an input into the 
software development ar.d maintenance process not an output. 
Lines of cede are necessary to produce a software program 
but cannot measure new the program functions. 

A major difficulty in implementing tha use of lines of 
code as a productivity measure is to define exactly what a 
line consists cf. Programs consist of more than executable 
lines of code. In addition to the executable statements, 
there may be jcb control language, comment statements, data 
declarations and macro-instructions. Depending upon what is 
or is not counted as a line, various measures of lines of 
code may differ by factors of two or more. 
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Another irajor difficulty in using lines of coda as a 
measure concerns its poor capabilities when measuring non- 
coding tasks. The entire program development process re- 
quires much more than coding. Most lines-of-code measures 
attempt to deal with this by using long-run measures which 
have seme average amount of nonceding work built into them. 
However, the application of lines of code per programmer- 
month to such tasks may result in questionable results in 
specific circumstance s. 

These measures also tend to penalize higher level lan- 
guages. The initial portions of the software development 
cycle, such as the determination of user requirements, spec- 
ifications and test cases, as well as later portions, such 
as the writing of documentation, do not depend upon the lan- 
guage utilized. Since higher level languages tend to re- 
quire fewer source statements to program than lower level 
languages, combination of the coding portion with the lan- 
guage-independent portions of development results in an ap- 
parent lesser productivity when using higher level languag- 
es. This apparent paradox exists because the productivity 
measure is just that and is net a measure of total cost. 

A problem related to the higher level language problem is 
that lines cf code does net adequately deal with quality 
differentials in different programs. Some efforts have been 
made to permit the introduction of quality measures within 
lines of code via the use of complexity metrics. Because 
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the field cf complexity metrics is still undergoing develop- 
ment with no dominant metric available, the use of such me- 
trics has not yet offered a precise solution to the quality 
measurement problem. 

The last major problem with lines of code is that it per- 
petuates the myth that coding is the predominant activity in 
software development and maintenance. This may have been 
the case in the early days of programming, but in, for exam- 
ple, modular programming there may be no new code created 
during a particular project. 

A relatively minor problem appears to be that, when such 
measures are applied to subtasks in a project ar.d then ag- 
gregated, the aggregation cf the subtask measures to a sin- 
gle overall measure is performed incorrectly. The correct 
method of aggregation depends upon whether the subtasks are 
performed simultaneously or sequentially. If they are per- 
formed simultaneously, the aggregate measure will be larger 
than any of the subtask measures, and, if they are performed 
sequentially, the aggregate measure will be smaller than any 
of the suttask measures. Combinations require that sequen- 
tial subtask measures be aggregated first, followed by ag- 
gregation cf the remaining simultaneous measures. 

As with all productivity measures, lines of code is sus- 
ceptible tc gaming. Programmers may be able to generate ap- 
parent increases in productivity where none really exists as 
well as apparently prevent decreases in productivity where 
such a decrease has actually occurred. 
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Despite the problems given above, lines of coda does have 
a major advantage in that it is relatively easy to measure. 
With judicious use, lines of cede may offer an excellent 
method for measuring programmer productivity. The following 
statement illustrates this: 

There is still a great deal tc be learned about 
quality and productivity normalized against, lines 
of code. We have not explored the limits of 
knowledge, and comparisons between different kinds 
cf programs — with lines of cods counted the same 
way for both — almost daily yield new insights and 
discoveries. It is premature to abandon this 
method, just when results are becoming encourag- 
ing . 5 

5.4.3 Program Fun ctions 

A productivity measure has been proposed and tested which 
is based upon functions performed by the program. The spe- 
cific measure is labor units (specifically, man-hours) per 
function. Note that this is not actually a productivity 
measure, but is the inverse of a productivity measure. As 
in the case of lines cf cede, program functions measures an 
input into the software development and maintenance process 
instead of an output. Although it is aole to measure how a 
program functions, this measure does not capture how users 
evaluate or utilize a particular piece of software. 



5 This quote (page 51) and some of the above discussion is 
taken frem Jcnes, T.C., "Measuring Programming Quality and 
Productivity," IBM Systems Journal, Vol. 17, No. 1, 1978, 

pp. 39-63. 
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Perhaps the most difficult aspect cf using program 
functions as a measure is the definition cf a program func- 
tion. Pricr applications have been limited to structured 
programming environments only. Within this structured ap- 
proach a function is defined to be a paragraph. Depending 
upon the particular language, a paragraph and, therefore, a 
function may be a procedure or a (sub) routine . This also 
corresponds to the concept of a module. Given a specific 
methcd of measuring program functions, this measure is rela- 
tively easy he calculate. However, this measure is also 
susceptible to gaming, depending upon the extent to which 
th e- indi v i dual programmer can control tae structure of -he 
program., 6 

5.4.4 User Functions 

A productivity measure has been proposed which is based 
upon external attributes or functions which are activated by 
the user. The general approach in this case is .to determine 
the external or user-oriented manifestations of any applica- 
tion software. In practice, this is accomplished by count- 
ing the number of external user inputs, outputs, ir.gurries 
and master files delivered by the project. 



6 A discussion of program functions may be found in Cross- 
man, T.D., "Taking the Measure of Programmer Productivi- 
ty," Datam atio n, May 19 79, pp. 144- 147. 



45 



The counts cf each ot these f 
to attempt to reflect the relati 
user. Albrecht suggests specifi 
to be useful in one particular o 
the weighted sum may be adjusted 
nary circumstances. The result 
counts for a specific project, 
by Albrecht was hours worked per 
the inverse of a productivity me 
The measure of user functions 
considerable advantage of actual 
output, user functions, of the s 
respect, if corresponds more clo 
measure than any of the other pr 
above. Since it is mere output- 
difficult to game than any of th 
The actual measurement of use 
cumstancss may be nontrivial, ho 
conceivable that one may have a 
whether a particular function is 
a different weight is allowed fo 
inquiries, the selection of part 
have an unintended effect upon t 
the measurement procedure. 7 



7 User functions are discussed i 
Application Development Produc 

SH ARE /GUIDE/I3M & EE. illation De 
1979 , ~pp7 83 - 92 ." 



our factors may be weighted 
ve value of each to the 
c weights which were found 
raanization. Additionally, 
to account for extraordi- 
is a measure of function 
The actual measure utilized 
function count, which is 
asure . 

per labor unit offers the 
ly attempting to measure the 
oftware process. In this 
sely to a true productivity 
egraaming measures discussed 
oriented, it is much more 
e other measures, 
r functions in specific cir- 
wever. For example, it is 
difficult time discerning 
an input or an inquiry. If 
r inputs than is allowed for 
icuiar user functions may 
he actual value generated by 

n Albrect, A.J., "Measuring 
tivity," Proc eedings of the 
velopm ent Symposi um, October 



46 



5. 4. 5 



Consisted Projects 

Another possible measure is completed projects per labor 
unit. This measure offers the advantage of being exception 
ally easy to inclement and use. However, unless a reason- 
ably large number of different categories of projects are 
maintained, this measure is also exceptionally susceptible 
to gaming. This is especially true if the individual to be 
measured has any input into the selection of which projects 
are to be programmed by whom. Also, the existence of a 
large number of categories compromises the ease-of-use ad- 
vantage of this measure. Similarly, it presents the addi- 
tional problem of cross comparisons of different measures 
when looking at a single programmer. 

5.4.6 Su mm ary 

Each of the above measures has unique advantages and dis 
advantages. This ensures that there is no one dominant 
measure for all situations. Since FMSO is ooth a develop- 
ment and a maintenance activity, these measures must be ex- 
amined for their specific comparative advantages in the de- 
velopment and/or maintenance processes. Along this 
dimension, the two functional measures, program functions 
and user functions, are useful primarily in the development 
process. The ether two measures, lines of code and complet 
ed projects, may be used for both development and mainte- 
nance. The measures also have relative advantages and dis- 
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advantages when used in either applications or systems 
programming projects. Note, additionally, that there are 
difficulties in making comparisons across different languag 
es or organizations but here we are interested only in meas 
uring the productivity of the programming process within 
FM SO . 

Hence, it is suggested that a pilot project be set up to 
collect data or. a number cf software projects and that sev- 
eral measures be evaluated using these data. This would re 
suit in two or possibly three measures being selected for 
further testing on a much larger sample. After a reasor.abl 
number of projects have been examined, then the measures ma 
be further evaluated tc produce an operational productivity 
measurement system. 

5.5 IMPLEMENTATION OF A PRODUCTIVITY MEASUREMENT SYSTEM 

Productivity measurement systems, despite the advantages 
discussed above, are not used universally. Perhaps the ma- 
jor reason for this is because these systems are not cost- 
less. Resources are required, from both managers and pro- 
grammers, in order to implement such systems. All of the 
measurement systems above are based on daily inputs by indi 
vidual programmers in order to keep track of labor units. 
Also, analysis of the project is necessary in order to gen- 
erate alternative output measures. However, such systems 
are, in general, cost-effective based upon their general us 
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age. In addition to --he measurement system's contribution 
to the potential increase in productivity, there are several 
other reasons that FMSO should begin to implement a produc- 
tivity measurement system. 

The major reason is that a similar system, designed to 
associate specific resources with specific software pro- 
jects, will be implemented in the near future by DOD. The 
Air Force is the lead service in the testing of the Software 
Acquisition Resource Expenditure (3 ARE) reporting system. 

New directives will require such reports for all software 
developed by and for DOD. Consequently, the forthcoming 
SARE reporting system will be much easier to implement if a 
data collection system has been tested and is being utilized 
by FMSO. 

Another possible reason for movement to a productivity 
measurement system by FMSO is to provide the Dasis for quan- 
titative justification of resources required for particular 
projects. Under the commercial activities program, all 
r.o n- mission-essential activities are subject to private sec- 
tor provision. In the case of software development and 
maintenance, this program would require FMSO to bid on par- 
ticular projects along with private sector software houses. 
Such bids must be auditable, which implies that productivity 
information must be guantitatively-based and verifiable. A 
related aspect is that the NARDAC's are moving to a NIF 
funding basis instead of a mission-funded basis. It is not 
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impossible that FMSO and its customers could be moved to 
such a fund accounting basis in the future. 

Although a productivity measurement system can provide 
reasonably precise and accurate information, it cannot in- 
crease productivity on its own. Other chapters of this re 
port provide other techniques and methods for dealing with 
productivity enhancement at FNSO. As tne following remark 
indicates, these other factors are also important. 



How workers feel about their jobs, about their 
fellow workers, about management, and aoout the 
organization, may be more important _n influencing 
productivity than is the particular way they are 
instructed to do their work, the formal organiza- 
tional structure, or even financial incentives. 0 



8 This is found on page 1038 of Nelson, 8.3. , "Research on 
Productivity Growth and Productivity Differences: Dead 

Ends and New Departures," The Journa l of Eco n o mi c lit era 
ture, Vol. 19, No. 3, September 1981, pp. 1029-1054. 
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Chapter 6 

A PROJECT PLANNING STSIES 



6. 1 introduction 

Software project management has never been an easy task. 
The area is characterized by slipped schedules, overdue de- 
liveries and systems that do not work as they were intended 
Over the years, we have gotten smarter about software syste 
development. We know more about how to do it, and we sett! 
for less than our most optimistic hopes. A manager thrown 
into this environment for the first time quickly comes to 
appreciate Fred Brooks metaphorical use of the LaBrea Tar 
Pits to characterize software development projects 9 . 

A great deal has been written about software project man 
agemer.t techniques lately. Naturally, most of the writeups 
are of success stories. In the normal manner of success 
stories, they make the project management process seem easi 
er than it prccaoly was. This is where the "Grass is Green 
er" syndrome begins to come in. We know that in cur own or 
ganizations, there are problems that sometimes get out of 
hand. These success stories sometimes make us think that 
everybody else has things under control. The answer then 
seems to be to take the methods that have (presumably) 



9 Fred Brooks, The Mythical Man- month , p. 3. 
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worked wall elsewhere and adapt them to our organizations. 

This would te a great idea if it were possible, but un- 
fortunately, there are a few hitches in the process. Soft- 
ware projects are not simple, and they are not standardized 
across organizations. The standards for measuring produc- 
tivity in different organizations are going to be vastly 
different. We can learn a lot about installing a project 
planning and control system by observing the techniques that 
have worked elsewhere, but we have to be careful. It is es- 
pecially dangerous to take productivity figures from one or- 
ganization as necessarily being indicative of what we can 
expect. First of all, we have to know what they think pro- 
ductivity is and how they account for it. That information 
rarely appears in the articles in sufficient detail to allow 
us tc reconstruct the measures used by the original re- 
searchers, much less use them m cur own organizations. 

What we will have to do is to develop our own models 
(probably patterned on these developed elsewhere), gather 
data on how they work, and gradually develop our own system 
for project estimating. This implies that a project estima- 
tion model has to be tailer made for a given organization. 
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